How to Give Great Feedback

Most managers and/or managerial candidates have heard of the concept of the “feedback sandwich”: give the target of the feedback a compliment at the beginning and another one at the end of the feedback session, and it will make it easier for the individual to swallow the whole load. Others have heard more recently of the idea of “radical candor” (popularized by the book of the same name), which suggests that the best way to give feedback is to be extremely candid, regardless of whether that candor is “positive” or “negative.”

Sadly, neither of these is actually a great approach to giving feedback. In an article entitled “The Feedback Fallacy” in the March-April 2019 issue of “Harvard Business Review,” Marcus Buckingham and Ashley Goodall pointed out “the research is clear: Telling people what we think of their performance doesn’t help them thrive and excel, and telling people how we think they should improve actually hinders learning.” They point out that in the business world, we think of the value of feedback because of three widely-held theories:

• The Theory of the Source of Truth. The employee does not (or may not) realize the truth of what is going on. That means it is up to you as their manager to point out the truth to them, because if you don’t, they’ll never know, and that would be bad.
• The Theory of Learning. The employee lacks certain abilities they need to acquire, so you should teach them. In other words, they need the feedback to develop the skills they’re missing, and you’re in a position to be able to tell them how to get them. Not sharing your feedback would prevent the employee from learning, which would be bad.
• The Theory of Excellence. Great performance is universal, analyzable, and describable, and that once defined, it can be transferred from one person to another, regardless of who each individual is. Hence your employee (or you) can, with feedback about what excellence looks like, understand where they (or you) fall short of this ideal and then strive to remedy the shortcomings.

Sadly, each of these theories turns out to be false (and the authors spend the bulk of the article describing the research that debunks each of them): “What these three theories have in common is self-centeredness: They take our own expertise and what we are sure is our colleagues’ lack of expertise as givens; they assume that my way is necessarily your way. But as it turns out, in extrapolating from what creates our own performance to what might create performance in others, we overreach.” In particular, regarding the last theory (excellence), they point out that “Excellence seems to be inextricably and wonderfully intertwined with whoever demonstrates it. Each person’s version of it is uniquely shaped and is an expression of that person’s individuality.” This makes itself wildly apparent in the realm of software development and design—those who are often accorded as the best developers in the world did so using tools, techniques, or approaches that differ wildly from each other. Consider this: ask any five senior developers what “great programmers” do, and they’ll likely all reply with some variant of “write great code”; when you ask them what “great code” looks like, with concrete examples, be prepared for some of the most wildly divergent answers you’ve ever heard. We simply don’t have a generalized standard for “great code.”

So what, then, do we do to offer up great feedback?

• Look for outcomes. Take note of when one of your team does something that generates a positive result. Turn to that person and emphasize the positive result; literally, point to it and shout, “Yes! That! More of that!” By doing this, it stops the flow of work for a moment and pull your employee’s attention toward something they just did (relatively speaking) that succeeded. (This is often best done as ad-hoc feedback and/or in the weekly 1:1.) Neurologically, this provides your direct with the chance to gain an insight: you’re highlighting a pattern that is already there inside their head, giving them a chance to recognize it, anchor it, recreate it, and refine it.

• Replay your instinctive reactions. Despite however great you are at programming, you are by no means the authority figure on what great performance looks like. (Any time you start to feel like you know “the way,” get out more, visit some conferences, and read some articles, and you’ll quickly be pulled back into sobering reality.) The key is not to tell someone how well they performed or how good they are; instead, describe what you experienced when their excellence caught your attention. One of my favorite phrases to use is, “Did you see what you did there?”—it wrenches them, almost literally, out of their train of thought and focuses their attention on what, in fact, they just did. It kicks them into an analytical mode, while at the same time allowing them to see what it was like to be in your head for just a moment. Best of all, you’re not judging or “rating” them (that’s what metrics can do later), you’re showing them how they just made a “dent” in your world. This is particularly powerful for junior developers, as they often don’t believe they have much of value to share because “they don’t know as much” as the others on the team—yet some of the most interesting and innovative solutions I’ve seen a team embrace have come from a “what if” kind of thought thrown out by a junior developer.

• Never lose sight of your highest-priority interrupt. The team is about to release a feature into production, and you can see that they’ve not run the test suite, or thought about the database migration, or something equally dangerous that could screw things up in a big way. The instinct will kick in to stop everything to tell someone what they did wrong and what they need to do to fix it, but keep in mind that this is just remediation (fixing the problem) and doesn’t actually improve anyone’s performance. Encouraging excellence out of your team requires a different focus from you: your highest-priority interrupt is to find when somebody is doing something excellent, and calling it out.

• Explore the present, past, and future. Naturally, there will be moments when you need to provide more traditional feedback; the employee may come to you asking directly for feedback, or you may need to help them walk through a situation which they feel they cannot handle. Buckingham and Goodall suggest, then, that you walk through the present, past and future, in that order, as a way to help them figure out for themselves what they need to do next:

  • Present. “Ask them to tell you three things that are working for them right now. These things might be related to the situation or entirely separate. They might be significant or trivial. Just ask the question, and you’re priming them with oxytocin—which is sometimes called the ‘love drug’ but which here is better thought of as the ‘creativity drug.’ Getting them to think about specific things that are going well will alter their brain chemistry so that they can be open to new solutions and new ways of thinking or acting.”
  • Past. “Ask them, ‘When you had a problem like this in the past, what did you do that worked?’ Much of our life happens in patterns, so it’s highly likely that they have encountered this problem at least a few times before. On one of those occasions they will almost certainly have found some way forward, some action or insight or connection that enabled them to move out of the mess. Get them thinking about that and seeing it in their mind’s eye: what they actually felt and did, and what happened next.”
  • Future. “Ask them, ‘What do you already know you need to do? What do you already know works in this situation?’ By all means offer up one or two of your own experiences to see if they might clarify their own. But operate under the assumption that they already knows the solution—you’re just helping them recognize it.”

Certainly, this isn’t always going to apply; if your team member comes to you asking about some particular quirk of the C++ programming language, it’s not going to help to ask them “What parts of C++ have you used in the past that worked?” But at a level deeper than the surface, the individual is asking you a particular fact or insight that is probably documented and/or explored in depth somewhere out in the world. Focus on the “whats”: “What do you actually want to have happen?” “What are a couple of actions you could take right now?” These sorts of questions yield concrete answers, which then provides them with the tools (and the confidence) to find answers for themselves later on. By giving them some tips/insights on how to discover for themselves how C++ works under the hood (such as reading Bjarne Stroustrup’s The Design and Evolution of C++ or Stan Lippman’s Inside the C++ Object Model, or writing some sample code and examining the resulting assembly or stepping through it in the debugger), you’re not just giving them the fish they want, you’re teaching them how to thread the rod and put worms on the hook for themselves.

The Avast Rule: To resist that urge to jump in and fix everything, consider what I call the “Avast!” rule: When my eldest son was in grade school (10 or 11 years old), his class took a field trip to a sailing ship docked in port. There, they “embarked” on an imaginative journey, pretending to be the sailors running the ship for a full day and night. The kids, literally, were the ones cooking the meals, tending the ropes, arranging the cargo, standing watch at night, and so on. As an adult chaperone (“tall sailors,” they called us), I was very carefully (and repeatedly) told that we adults could not correct the kids when they did something wrong; we could only say, “Avast!”. That was the kids’/sailors’ cue that something was wrong, and the kids had to not only figure out what they were doing wrong, but figure out for themselves how to correct it. It might take longer, but the point of the exercise was to make sure the kids were learning how to recognize the flaw, and fix it themselves, rather than rely on the adults for help. (And for those curious, they did a pretty good job with both the meals and the coffee that was available for the adults to stay awake during our own watch schedule at night.)

Having said all that, don’t let the takeaway be “never offer constructive criticism”; quite the opposite. Employees still need that corrective guidance when they aren’t seeing the path for themselves. Just be aware that the way that you would do it isn’t the only way—so long as they get the job done (focus on outcomes), does it really matter how? I once had a team that was working on a research project, and where I thought I’d attack the problem one way, the team chose to go an entirely different direction—and did so successfully. That’s a win, and I’m glad I kept my focus on the outcome, rather than their choices along the way.